The Service Oriented Architecture (SOA) is a popular architectural paradigm for the development of software applications. For example, web services provide the SOA to other applications via industry standard network, interfaces and protocols. The SOA is based on loosely-coupled and standards-based architectures. It is one approach to distributed computing that allows networked software resources to be leveraged.
An Enterprise Service Bus (ESB) is an underlying infrastructure for the SOA. An ESB server implements the abstract design concept of the SOA. The ESB server is an event-driven and standards-based messaging engine that provides services for more complex architectures. The ESB server provides an infrastructure that links together services and clients to enable distributed applications and processes. The ESB server can be run on one or more nodes, and each node can be a virtual or physical machine running one or more instances of the ESB server. The ESB server allows systems to interact through standard transports, such as file transfer protocol (FTP) and hypertext transfer protocol (HTTP), and to provide SOA-based applications. The ESB server provides the capabilities of message handling, filtering, data transformation, content-based routing, and message repositories. The ESB server provides the above capabilities to a client using a service deployed on an ESB server at runtime that exchanges messages with the client. The service may be defined as a list of action classes that process an incoming message in a sequential manner, for example. The ESB server allows for the distribution of service instances across many nodes.
The ESB server provides an effective way of processing various kinds of messages and events. Unfortunately, conventionally, there is no way for the ESB server to execute any actions other than those actions associated with receiving an incoming message (or event) targeted for a service deployed on the ESB server and directing the incoming message to the targeted service. The service deployed on the ESB server may detect certain conditions for a particular message (or event) to invoke another service, but the ESB server cannot detect the conditions to invoke the other service, as illustrated in the conventional approach of FIG. 1.
FIG. 1 illustrates one approach to forward a message from one service to another in a conventional ESB server configuration. In this example, the Services A and B guarantee fast message processing. To satisfy this requirement, the Services A and B defer message processing to Service D for messages larger than 50 KB, for example. It should be noted that Service C does not have such a requirement. In order to forward messages that meet that conditions, Services A and B contain custom configurable actions or customizable code that says, for example: If message_size>50 KB Then Forward message to Service D. Whenever the requirement is modified, such as setting the message size threshold to 75 KB, a programmer has to remove the condition or create a new condition according to the new business rules within the code for both Services A and B. Since the code of both Services A and B have been modified, and since the actions have been modified, the code corresponding to Services A and B (and possibly other related code) would also need to be recompiled for the new business rules to be implemented. Similarly, if the programmer desires Service C to provide such functionality, the programmer has to modify Service C with the new business rules and recompile the code for the Service C.